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Abstract 

The  use  of  product  lines  is  recognized  as  beneficial  in 
promoting  and  structuring  both  component  and  architec¬ 
ture  reuse  throughout  an  organization.  While  the  busi¬ 
ness  practices  of  using  product  lines  are  well-understood 
and  representations  for  specifying  and  capturing  the  un¬ 
derlying  architecture  of  a  product  line  are  coming  of  age, 
support  environments  for  managing  the  evolution  of  a 
product  line  architecture  are  still  lacking.  In  this  paper, 
we  present  Menage,  an  environment  specifically  designed 
to  alleviate  this  problem.  Key  features  of  Menage  are  its 
support  for:  (1)  specifying  variation  points  in  a  product 
line  architecture  as  optional  and/or  variant  elements,  (2) 
tracking  the  evolution  of  a  product  line  architecture  and 
its  constituent  elements  through  explicit  versioning  tech¬ 
niques,  and  (3)  selecting  one  or  more  product  architec¬ 
tures  out  of  an  overall  product  line  architecture  by  apply¬ 
ing  user-specified  criteria.  In  this  paper,  we  introduce 
the  approach  underlying  Menage,  discuss  its  detailed 
functionality,  and  demonstrate  its  use  with  a  product  line 
architecture  for  entertainment  systems. 

1.  Introduction 

The  use  of  product  lines  in  industrial  software  devel¬ 
opment  is  steadily  gaining  acceptance,  especially  since  it 
has  been  shown  that  their  disciplined  use,  as  backed  by 
strong  organizational  commitment,  can  lead  to  significant 
advantages  in  terms  of  reduced  development  cost  and  time 
[2,4,6].  Organizations  such  as  Nokia  [18],  Alcatel  [22], 
and  Philips  [11]  have  already  reported  on  successfully 
introducing  product  lines  for  some  of  the  software  they 
are  developing.  Other  organizations  are  not  far  behind 
[23]. 

Instead  of  focusing  on  developing  a  single  product  at  a 
time  (or,  at  best,  multiple,  relatively  independent  prod¬ 
ucts  in  parallel),  the  use  of  a  product  line  carefully  coor¬ 
dinates  the  design,  development,  and  evolution  of  a  set  of 
intimately  related  products.  As  compared  to  component- 
based  software  development  [15],  this  entails  a  paradigm 
shift  from  component  reuse  to  architecture  reuse.  Compo¬ 
nent-based  software  development  focuses  on  the  creation 


of  reusable  component  implementations  that  are  subse¬ 
quently  integrated  and  adapted  to  form  entirely  new,  often 
unrelated  applications.  The  use  of  a  product  line,  on  the 
other  hand,  is  firmly  rooted  in  the  development  of  a  stan¬ 
dard  product  line  architecture  that,  along  with  a  standard 
set  of  components  implementing  the  core  of  the  architec¬ 
ture,  forms  a  reusable  basis  for  the  development  of  new, 
closely  related  members  in  the  product  line. 

The  issues  involved  in  creating  a  development  process 
and  business  environment  tailored  to  the  use  of  a  product 
line  architecture  are  relatively  well  understood  [4].  Addi¬ 
tionally,  representations  for  specifying  and  storing  prod¬ 
uct  line  architectures  have  already  been  developed 
[3,10,14,32].  Effective  use  of  a  particular  product  line 
architecture,  however,  also  requires  a  support  environment 
to  manage  its  evolving  structure — an  area  of  research  that 
has  largely  been  ignored  to  date. 

This  paper  introduces  Menage,  an  environment  that  is 
specifically  designed  to  fill  this  void.  Menage  builds 
upon  our  existing  representation  for  product  line  architec¬ 
tures,  xADL  2.0  [9,10],  to  provide  a  software  architect 
with  three  capabilities  that  are  explicitly  geared  towards 
managing  an  evolving  product  line  architecture.  First, 
Menage  supports  the  specification  of  a  product  line  archi¬ 
tecture  as  a  set  of  core  architectural  elements  that  is  aug¬ 
mented  with  variation  points.  These  variation  points  are 
optional,  variant,  or  optional  variant  elements,  and  pre¬ 
cisely  define  the  dimensions  along  which  individual 
product  architectures  structurally  differ  from  each  other. 

Second,  Menage  uses  explicit  versioning  techniques  to 
track  the  evolution  of  all  parts  of  a  product  line  architec¬ 
ture.  Every  element,  ranging  from  an  individual  interface 
type  to  the  overall  product  line  architecture  (which  poten¬ 
tially  can  be  very  large),  is  explicitly  versioned  and  must 
be  checked  out  before  it  can  be  modified  and  checked  in 
after  the  modifications  are  complete. 

Finally,  Menage  allows  an  architect  to  select  one  or 
more  product  architectures  out  of  an  overall  product  line 
architecture.  Using  a  user- specified  set  of  criteria  (which 
are  expressed  as  name- value  pairs),  Menage  creates  a  re¬ 
duced  version  of  the  original  product  line  architecture.  If 
all  variation  points  are  completely  resolved,  the  result  is  a 
single  product  architecture;  if  one  or  more  variation  points 
remain  (partially)  unresolved,  the  result  is  a  smaller  prod- 


uct  line  architecture  containing  fewer  product  architec¬ 
tures.  Additional  selections  may  be  performed  to  further 
reduce  the  size  of  the  product  line  architecture  and  its 
number  of  available  product  architectures. 

The  remainder  of  this  paper  is  organized  as  follows. 
First,  in  Section  2,  we  discuss  relevant  background  mate¬ 
rial  in  the  field  of  product  line  architectures.  We  detail  the 
problem  of  managing  the  evolution  of  product  line  archi¬ 
tectures  in  Section  3,  and  introduce  the  approach  underly¬ 
ing  Menage  in  Section  4.  We  describe  Menage  in  detail  in 
Section  5,  and  show  its  application  on  an  entertainment 
system  product  line  architecture  in  Section  6.  We  discuss 
related  work  in  Section  7  and  conclude  in  Section  8  with 
an  outlook  at  our  future  work. 


2.  Background 

Software  architectures  provide  high-level  abstractions 
for  representing  the  structure,  behavior,  and  key  properties 
of  a  software  system  [21].  These  abstractions  typically 
involve:  (1)  descriptions  of  the  elements  from  which  sys¬ 
tems  are  built,  (2)  interactions  among  those  elements,  (3) 
patterns  that  guide  their  composition,  and  (4)  constraints 
on  those  patterns.  In  general,  a  software  architecture  is 
defined  as  a  set  of  components ,  a  set  of  interconnections 
among  those  components  (connectors),  and  the  overall 
organization  of  the  components  and  connectors  into  a 
single  system  (configuration). 

Whereas  a  “regular”  software  architecture  only  defines 
the  structure  of  a  single  software  system,  a  product  line 
architecture  defines  the  architectural  structure  for  a  set  of 
related  products  [4,6].  As  such,  a  product  line  architecture 
consists  of  a  set  of  closely  related  product  architectures , 
each  product  architecture  defining  the  software  architecture 
of  one,  unique  product  in  the  product  line.  To  maximize 
reuse  and  understanding,  a  product  line  architecture  dis¬ 
tinguishes  core  elements  that  are  present  in  all  product 
architectures  from  variation  points  that  capture  differences 
among  specific  product  architectures.  Three  kinds  of  varia¬ 
tion  points  are  used  to  distinguish  different  product  archi¬ 
tectures  from  each  other:  (1)  optional  elements,  which 
describe  architectural  elements  that  may  or  may  not  be 
present  in  a  particular  product  architecture,  (2)  variant 
elements,  which  define  elements  that  are  always  present, 
but  can  be  configured  to  be  one  of  many  alternatives,  and 
(3)  optional  variant  elements,  which  specify  variant  ele¬ 
ments  that  may  or  may  not  exist.  A  particular  product 
architecture  is  selected  out  of  a  product  line  architectures 
by  determining,  for  each  optional  element,  whether  or  not 
it  is  included,  and,  for  each  variant  element,  which  variant 
is  incorporated. 

Figure  1  introduces  a  simple  example  in  the  form  of  a 
hypothetical  product  line  architecture  for  a  set  of  related 
word  processors.  Solid  boxes  indicate  core  components, 
dashed  boxes  indicate  variation  points  consisting  of  op¬ 
tional  components,  and  stacks  indicate  variation  points 
consisting  of  variant  components.  In  this  case,  a  product 
architecture  for  one  particular  word  processor  always  in¬ 


corporates  its  three  core  components  (USER  INTERFACE, 
Layout  engine,  and  Storage),  may  or  may  not  in¬ 
clude  the  optional  component  Print,  and  always  includes 
a  variant  of  the  spell  checking  component  (English  spell 
checker,  Dutch  spell  checker,  or  French  spell 
CHECKER).  While  the  example  presents  a  trivial  product 
line  architecture  that  consists  of  only  a  small  set  of  com¬ 
ponents,  one  can  easily  imagine  more  complicated  prod¬ 
uct  line  architectures  consisting  of  many  components  and 
connectors  with  many  complex  and  interrelated  variation 
points.  The  product  line  architecture  for  Philips  televi¬ 
sions  is  one  example  of  a  real-life  product  line  that  exhib¬ 
its  many  of  these  characteristics  [11]. 

Perry  [24]  outlined  the  space  of  possibilities  for  mod¬ 
eling  product  line  architectures  and  observed  that  a  prod¬ 
uct  line  architecture  modeling  technique  must  be  both 
generic  enough  to  encompass  all  members  of  the  product 
line  architecture  and  specific  enough  to  provide  developers 
with  adequate  support  for  instantiating  and  implementing 
individual  product  architectures.  While  it  is  technically 
possible  to  reuse  architectural  styles  for  this  purpose  [28], 
experience  with  product  line  architectures  has  shown  a 
need  for  higher-level  support  in  terms  of  explicit  facilities 
for  modeling  variation  points  [10,32]. 


Figure  1.  Example  Product  Line  Architec¬ 
ture. 


Architecture  description  languages  support  architec¬ 
ture-based  development  [21]  by  providing  formal  nota¬ 
tions  to  describe  the  architecture  of  a  software  system.  An 
architecture  description  language  is  usually  accompanied 
by  various  tools  for  parsing,  analysis,  simulation,  and 
code  generation  of  a  modeled  system.  Examples  of  archi¬ 
tecture  description  languages  include  C2SADEL  [20], 
Darwin  [19],  Rapide  [17],  UniCon  [27],  and  Wright  [1]. 
A  number  of  these  languages  also  provide  extensive  sup¬ 
port  for  modeling  behaviors  and  constraints  on  the  prop¬ 
erties  of  components  and  connectors  [21].  However,  with 
the  exception  of  xADL  2.0  [10],  Koala  [32],  GenVoca  [3] 
and  to  some  extent  Acme  [14],  existing  architecture  de¬ 
scription  languages  do  not  directly  support  the  specifica¬ 
tion  of  product  line  architectures.  Given  the  importance  of 
product  lines  in  today’s  world  of  software  development, 
we  expect  this  situation  to  change  rapidly. 

3.  Problem 


It  is  well  known  that  even  a  simple  software  architec¬ 
ture  typically  evolves  at  least  somewhat  over  its  lifetime. 
By  the  very  nature  of  a  product  line  architecture,  it  is  no 
surprise  that  its  overall  structure  changes  far  more  fre¬ 
quently  [5,7]:  new  product  architectures  are  added,  exist¬ 
ing  product  architectures  must  be  modified  in  response  to 
changing  functionality  requirements,  and  defunct  product 
architectures  may  have  to  be  retired.  As  a  result,  a  product 
line  architecture  finds  itself  in  constant  flux  as  significant 
parts  of  the  product  line  architecture  change.  For  instance, 
optional  elements  may  turn  into  core  elements  (and  vice 
versa),  new  variants  may  be  added  to  a  variation  point,  a 
component  may  be  further  broken  down  into  subcompo¬ 
nents,  wholly  new  product  architectures  may  be  added;  or 
sets  of  existing  product  architectures  may  need  to  be  re¬ 
factored. 

Two  fundamental  concerns  for  using  a  product  line  ar¬ 
chitecture,  then,  are  how  to:  (1)  represent  and  capture  the 
evolution  of  a  product  line  architecture,  and  (2)  support  an 
architect  in  managing  such  evolution.  A  number  of  differ¬ 
ent  solutions  to  the  first  concern  have  been  proposed, 
including  using  a  generic  configuration  management  sys¬ 
tem  [32],  creating  a  new  architecture  description  language 
that  explicitly  integrates  facilities  for  modeling  evolving 
product  line  architectures  (e.g.,  variation  points,  versions) 
[10],  and  using  feature-oriented  domain  models  [16]. 
Technically,  most  of  these  solutions  are  able  to  provide 
more-or-less  equivalent  kinds  of  functionality. 

The  focus  of  this  paper  is  on  the  second  concern:  how 
to  help  an  architect  in  managing  the  evolution  of  a  prod¬ 
uct  line  architecture.  Existing  environments  for  architec¬ 
tural  design  (e.g.,  ArchStudio  2.0  [20],  AcmeStudio  [14]) 
provide  little-to-no  support  for  this  activity.  They,  for 
example,  are  not  equipped  to  handle  different  versions  of 
components  or  connectors,  provide  no  explicit  change 
process,  and  are  focused  on  the  development  of  a  single 
software  architecture  rather  than  a  set  of  related  product 
architectures  organized  in  a  product  line  architecture.  The 
goal  of  the  research  presented  in  this  paper  is  to  amelio¬ 
rate  this  problem  and  provide  architects  with  a  compre¬ 
hensive  design  environment  that  explicitly  supports  them 
in  managing  evolving  product  line  architectures. 

4.  Approach 

The  cornerstone  of  our  approach  lies  in  the  observation 
that  a  design  environment  for  evolving  product  line  archi¬ 
tectures  must  provide  an  architect  with  integrated  architec¬ 
tural  and  configuration  management  functionality.  Con¬ 
sider,  for  instance,  an  architect  who  wants  to  quickly  ex¬ 
amine  a  previous  version  of  their  product  line  architecture. 
The  architect  should  not  have  to  go  to  their  configuration 
management  system,  check  out  the  previous  version,  and 
then  open  it  in  their  design  environment.  Rather,  a  sup¬ 
port  environment  for  managing  evolving  product  line 
architectures  must  allow  an  architect  to  simply  choose  a 
version  to  view,  with  the  environment  itself  taking  care  of 
accessing  the  underlying  store  to  obtain  any  necessary 


data  (regardless  of  whether  that  store  is,  for  example,  a 
configuration  management  system  [32]  or  an  architecture 
description  language  that  has  specific  features  for  model¬ 
ing  product  line  architectures  [10]).  Numerous  other  ex¬ 
amples  exist  of  situations  in  which  architects  must  simul¬ 
taneously  access  or  manipulate  information  that  is  related 
to  both  the  structure  and  evolution  of  a  product  line  archi¬ 
tecture.  Without  an  integrated  approach,  architects  will 
not  be  able  to  effectively  perform  their  work. 

Despite  the  need  for  an  integrated  approach,  the  pri¬ 
mary  focus  of  any  environment  for  product  line  architec¬ 
tures  should  remain  on  design.  The  primary  task  of  archi¬ 
tects,  after  all,  is  to  design,  precisely  specify,  and  main¬ 
tain  product  line  architectures. 

Overall,  then,  our  approach  is  rooted  in  the  following 
overarching  objectives: 

•  An  architect  should  be  able  to  design  a  product  line 
architecture  much  like  they  design  a  “regular”  archi¬ 
tecture.  In  particular,  the  familiar  approach  of  simply 
combining  components  and  connectors  must  be  pre¬ 
served. 

•  Variation  points  should  be  explicit  within  a  product 
line  architecture,  yet  seamlessly  integrated  in  the  de¬ 
sign  process.  For  instance,  the  difference  between 
adding  a  core  component  and  an  optional  component 
should  be  minimal. 

•  Evolution  should  be  managed  with  an  explicit  change 
management  process.  In  particular,  it  is  important 
that  a  meaningful  history  of  changes  is  created  when 
an  architect  modifies  a  product  line  architecture.  The 
change  management  process  should  be  non-obtrusive 
to  allow  an  architect  to  focus  on  their  task  at  hand. 

•  The  environment  should  automate  as  much  support 
as  possible.  For  instance,  selection  of  a  particular 
product  architecture  or  subset  of  product  architectures 
(a  “smaller”  product  line  architecture)  should  not  re¬ 
quire  manual  interpretation  of  variation  points. 

Together,  these  objectives  create  an  environment  for  man¬ 
aging  evolving  product  line  architectures  that  is  familiar 
and  easy  to  use,  and  that  provides  an  architect  with  auto¬ 
mated  and  extensive  support  in  all  aspects  of  managing  a 
product  line  architecture — ranging  from  initial  inception, 
throughout  many  changes,  to  eventual  selection  of  indi¬ 
vidual  product  architectures. 

5.  Implementation 

Figure  2  presents  the  overall  architecture  of  Menage,  as 
consisting  of  three  components.  At  the  lowest  level,  Me¬ 
nage  uses  the  xADL  2.0  libraries,  which  provide  a  pro¬ 
grammatic  interface  to  load  and  store  (parts  of)  particular 
product  line  architectures  [10].  Two  components  use  those 
libraries:  a  design  environment  and  a  selector.  The  design 
environment  component  provides  an  architect  with  facili¬ 
ties  to  graphically  create,  inspect,  and  modify  product  line 
architectures.  The  selector  component  complements  the 
design  environment  by  providing  an  architect  the  ability 
to  select  a  subset  of  one  or  more  product  architectures  out 


of  a  product  line  architecture.  Architecturally,  we  sepa¬ 
rated  the  design  environment  from  the  selector,  since  the 
selector  by  itself  provides  functionality  that  can  be  em¬ 
ployed  at  times  when  the  full  design  environment  is  not 
needed  (for  instance,  during  product  selection  at  a  cus¬ 
tomer  site).  Below,  we  discuss  the  details  of  each  of  the 
components. 


Figure  2.  Menage  Architecture. 


5.1  xADL  2.0  Libraries 

The  xADL  2.0  libraries  [10]  provide  a  programmatic 
interface  to  xADL  2.0  documents  containing  descriptions 
of  product  line  architectures.  Specifically,  the  libraries 


Options  schema  allows  for  the  definition  of  architectural 
elements  that  are  optional  in  a  product  line  architecture. 
Optionality  is  governed  by  a  Boolean  guard  that  deter¬ 
mines  the  conditions  under  which  the  optional  element 
should  be  included  in  a  particular  product  architecture. 

Boolean  guards  also  form  the  core  of  the  Variants 
schema.  In  particular,  a  component  (connector)  type  may 
be  a  “variant  type”,  which  means  that  it  is  a  placeholder 
for  a  set  of  other  component  (connector)  types.  Mutually 
exclusive  Boolean  guards  determine  which  type  is  eventu¬ 
ally  used  in  a  selected  product  architecture.  Of  note  is  that 
optionality  is  dealt  with  at  the  structural  level  (e.g.,  an 
element  may  or  may  not  be  part  of  the  structure  of  a 
product  line  architecture)  and  variability  at  the  type  level 
(e.g.,  the  type  of  a  component  or  connector  is  one  of 
many).  Therefore,  combined  optional  variant  elements  are 
naturally  supported  by  xADL  2.0. 

Finally,  the  VERSIONS  schema  allows  the  modeling  of 
the  evolution  of  a  product  line  architecture.  Each  type  is 
versioned  and  different  versions  of  a  type  are  organized  in 
a  version  graph.  An  architect,  thus,  can  keep  track  of  the 
evolution  of  both  individual  elements  and  the  structure  of 


Figure  3.  Specifying  a  New  Version  of  a  Component  Type  in 

Menage. 


provide  facilities  to  create,  load,  store,  and  modify  xADL 
2.0  documents.  While  xADL  2.0  is  built  as  a  set  of  ex¬ 
tensible  XML  schemas,  the  libraries  hide  all  XML  details 
and  allow  other  components  (e.g.,  the  design  environment 
and  selector)  to  manipulate  xADL  2.0  documents  in  terms 
of  architectural  elements  such  as  components,  connectors, 
and  interfaces. 

The  full  functionality  and  the  degree  of  extensibility 
offered  by  xADL  2.0,  as  well  as  its  benefits  as  compared 
to  other  languages  such  as  Acme  [14]  or  Koala  [32],  are 
beyond  the  scope  of  this  paper  and  described  elsewhere 
[10].  Of  importance  here,  however,  are  the  features  that  it 
provides  for  modeling  product  line  architectures.  We  de¬ 
scribe  these  features  briefly. 

The  core  of  xADL  2.0  is  formed  by  its  Structure 
and  Types  schema,  which  defines  modeling  constructs 
for  capturing  a  product  architecture  at  design-time.  Spe¬ 
cifically,  the  schema  allows  the  definition  of  the  structure 
of  one  particular  product  architecture  in  terms  of  a  set  of 
components  and  connectors.  Both  components  and  con¬ 
nectors  exhibit  interfaces,  which  are  the  elements  that  are 
linked  together  to  form  the  overall  structure  of  the  product 
architecture  (e.g.,  two  components  can  be  “hooked  up”  via 
a  connector  by  placing  links  in  between  interfaces  on  the 
components  and  interfaces  on  the  connector).  All  elements 
are  typed,  and  the  Structure  and  Types  schema  sup¬ 
ports  the  specification  of  subarchitectures  to  address  seal- 
ability  in  architectural  specification. 

The  xADL  2.0  Options  and  Variants  schemas  ex¬ 
tend  the  Structure  and  Types  schema  with  variation 
points,  thereby  enhancing  modeling  support  in  xADL  2.0 
from  individual  product  architectures  to  multiple  product 
architectures  as  related  in  a  product  line  architecture.  The 


the  overall  product  line  architecture. 

5.2  Design  Environment 

The  design  environment  is  the  component  that  an  ar¬ 
chitect  uses  to  initially  specify  and  then  maintain  an 
evolving  product  line  architecture.  Shown  in  Figure  3,  the 
graphical  user  interface  is  partitioned  into  three  separate 
panels.  The  panel  on  the  left  side  lists  component  types, 
connector  types,  and  interface  types  that  have  been  previ¬ 
ously  defined.  Instances  of  these  types  can  be  used  to 
construct  other  types.  The  top  panel  shows  the  version 
graph  of  the  type  that  is  currently  displayed  in  the  main 
panel.  Simply  clicking  on  one  of  the  version  nodes  brings 
up  the  structure  for  that  version.  Finally,  the  main  panel 
is  where  actual  design  of  a  product  line  architecture  takes 
place.  Menage  provides  a  large  number  of  different  edit 
operations  in  support  of  this  activity,  ranging  from  add¬ 
ing  components  and  connectors,  to  connecting  two  com¬ 
ponents  via  their  interfaces,  to  creating  and  using  subar¬ 
chitectures,  and  many  other  kinds  of  useful  functionalities 
that  are  customary  in  architectural  design  environments. 

An  important  aspect  of  Menage  is  that,  during  editing, 
it  always  displays  the  type  of  every  architectural  element, 
both  in  terms  of  its  type  name  and  type  version.  Rather 
than  relying  on  a  default  versioning  model  such  as  always 
using  a  latest  version,  use  of  specific  versions  of  architec¬ 
tural  elements  allows  an  architect  to  precisely  control  the 
evolution  of  a  product  line  architecture  in  terms  of  which 
versions  are  used,  where  those  versions  are  used,  and 
when  the  versions  are  changed.  In  the  example  of  Figure 
3,  for  instance,  one  can  quickly  discern  that  the  architect 
is  currently  editing  WORDPROCESSOR  component  type 


version  4,  and  that  it  in  turn  consists  of  instances  of  ver¬ 
sions  of  other  component  and  connector  types  (e.g.,  a 
User  Interface  component  of  type  VisualBasic  ver¬ 
sion  1,  a  Storage  component  of  type  Files  ys- 
temStorage  version  2,  etc.).  Because  connectors  and 
interfaces  are  visually  too  small  to  contain  the  same  level 
of  information,  tool  tips  are  used  to  provide  their  relevant 
data  (as  shown  for  the  interface  Print  of  interface  type 
Top  version  1). 

5.2.1  Change  Process 

Before  any  changes  can  be  made,  Menage  requires  an 
architect  to  check  out  the  set  of  architectural  elements  they 
will  be  modifying.  After  that,  the  architect  is  free  to  ma¬ 
nipulate  those  elements  in  order  to  change  the  product 
line  architecture.  Once  all  desired  changes  have  been 
made,  the  architect  checks  in  the  modified  parts  of  the 
product  line  architecture.  In  response,  Menage  automati¬ 
cally  creates  a  new  version  of  each  element  and,  in  the 
process,  creates  a  history  of  changes  that  can  be  revisited 
over  time.  This  history  is  critical  in  managing  the  evolu¬ 
tion  of  a  product  line  architecture:  it  captures  all  the 
changes  over  time,  relates  those  changes  to  each  other, 
and  allows  an  architect  to  revisit  previous  versions  to 
understand  the  nature  of  past  changes. 

During  the  change  process,  it  may  happen  that  an  ar¬ 
chitect  loses  track  of  which  elements  they  currently  have 
checked  out.  Menage,  therefore,  provides  a  mode  in  which 
it  highlights  those  elements  in  a  different  color.  Moreo¬ 
ver,  it  supports  an  architect  in  checking  in  either  a  single 
element,  an  element  and  the  hierarchically  contained  ele¬ 
ments  that  are  currently  checked  out,  or  all  checked  out 
elements.  The  latter  two  options  allow  an  architect  to 
check  in  related  changes  as  a  group. 


Once  a  version  has  been  checked  in,  that  version  be¬ 
comes  immutable.  It  can  no  longer  be  modified  in  order 
to  protect  any  other  parts  of  the  product  line  architecture 
that  depend  on  the  immutable  element.  This  guarantees 
incremental  stability  as  a  product  line  architecture  is  de¬ 
signed,  and  during  maintenance  guarantees  the  integrity  of 
the  old  versions  of  the  product  line  architecture. 

If  an  old  version  must  be  changed  nonetheless,  proper 
procedure  requires  that  it  is  checked  out  again,  thereby 
creating  a  branch.  Version  2.1  of  the  WordProcessor 
component  type  is  an  example  of  such  a  branch.  Cur¬ 
rently,  Menage  provides  no  support  for  merging  branches, 
but  we  are  in  the  process  of  adapting  our  architectural 
differencing  and  merging  algorithms  [30]  to  be  able  to 
operate  on  product  line  architectures. 

5.2.2  Variation  Points 

Menage  supports  the  specification  of  all  three  kinds  of 
variation  points:  optional  elements,  variant  types,  and 
optional  variant  elements.  Optional  elements  are  added 
just  as  regular  elements,  simply  by  providing  a  Boolean 
guard  at  the  time  of  creation  of  the  element.  The  Boolean 
guard  has  to  adhere  to  the  following  BNF: 

<BooleanGuard>  <BooleanExp> 

<BooleanExp>  ::=  <And>  |  <0r>  |  <Not>  |  <GreaterThan>  | 

<GreaterThanOrEquals>  |  <LessThan>  |  <LessThanOrEquals>  | 
<Equals>  |  <NotEquals>  |  <lnSet>  |  <lnRange>  |  <Bool>  |  <Paren> 
<And>  ::=  <BooleanExp>  &&  <BooleanExp> 

<0r>  ::=  <BooleanExp>  ||  <BooleanExp> 

<Not>  ::=  !<BooleanExp> 

<GreaterThan>  ::=  <LeftOperand>  >  <RightOperand> 
<GreaterThanOrEquals>  ::=  <LeftOperand>  >=  <RightOperand> 
<LessThan>  ::=  <LeftOperand>  <  <RightOperand> 
<LessThanOrEquals>  ::=  <LeftOperand>  <=  <RightOperand> 

<Equals>  ::=  <LeftOperand>  ==  <RightOperand> 

<NotEquals>  ::=  <LeftOperand>  !=  <RightOperand> 

<lnSet>  ::=  <LeftOperand>  @{  <Set> } 
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Figure  4.  Viewing  a  Variant  Component  Type. 


<lnRange>  ::=  <LeftOperand> 

@[  <RightOperand>,  <RightOperand>  ] 

<Paren>  ::=  ( <BooleanExp> ) 

<Set>  ::=  <RightOperand>  |  <RightOperand>,  <Set> 

<LeftOperand>  ::=  Variable 
<RightOperand>  ::=  Variable  |  Value 
<Bool>  ::=  true  |  false 

Most  Boolean  guards  will  be  of  a  rather  trivial  nature. 
The  availability  of  a  rich  language,  however,  allows  archi¬ 
tects  to  establish  intricate  relationships  among  variation 
points.  For  instance,  one  can  model  that  selection  of  a 
particular  variant  in  one  variant  type  should  lead  to  the 
selection  of  a  specific  other  variant  in  another  variant  type 
by  carefully  matching  the  Boolean  guards  on  the  variants. 

Graphically,  optional  elements  are  shown  using  dashed 
lines.  The  component  Print  in  Figure  3,  for  instance,  is 
an  optional  component.  Note  that,  because  the  Print 
component  is  optional,  its  link  to  the  connector  Busl  is 
automatically  optional  as  well.  If  the  Print  component  is 
included  in  a  particular  product  architecture,  the  link  is 
included  as  well;  otherwise,  it  is  left  out. 

Menage  treats  variant  types  in  a  special  way.  Instead  of 
containing  a  subarchitecture  of  components  and  connec¬ 
tors,  a  variant  type  only  contains  references  to  other  types. 
As  shown  in  Figure  4,  references  are  guarded  with  mutu¬ 
ally  exclusive  Boolean  expressions  to  ensure  that  only 
one  type  can  be  selected  at  a  time.  The  guards  are  used  to 
ensure  that  only  a  single  spelling  checker  component  can 
be  selected  covering  one  particular  language.  Of  note  is 
that,  in  the  case  of  the  example,  the  interfaces  on  the  vari¬ 
ants  are  exactly  the  same  to  the  interfaces  on  the  overarch¬ 
ing  variant  type.  The  general  rule  that  is  followed  in  Me¬ 
nage  is  that  interfaces  may  differ,  but  that  optionality 


should  be  used  to  ensure  compliance.  For  instance,  sup¬ 
pose  that  the  Dutch  spell  checker  also  has  an  interface  for 
thesaurus  functionality.  Such  an  interface  should  be  de¬ 
clared  optional  at  the  level  of  the  variant  type,  since  not 
all  variants  provide  this  interface.  This  guarantees  com¬ 
patibility  within  the  remainder  of  the  product  line  archi¬ 
tecture,  irrespective  of  which  variant  is  eventually  se¬ 
lected. 

When  an  instance  of  a  variant  component  or  connector 
type  is  used  in  a  product  line  architecture,  Menage  high¬ 
lights  that  component  or  connector.  This  makes  it  easier 
for  an  architect  to  locate  variation  points  (see,  for  exam¬ 
ple,  the  annotation  of  the  Spell  Checker  component  in 
Figure  3). 

Of  note  is  that,  because  optionality  is  expressed  at  the 
level  of  the  structure  of  the  product  line  architecture  and 
because  variability  is  expressed  using  types,  the  two 
seamlessly  combine  to  create  optional  variant  elements. 
To  do  so,  an  architect  adds  a  new  instance  of  a  variant 
type  and  annotates  it  with  a  Boolean  guard  that  deter¬ 
mines  its  inclusion.  Given  that  individual  variants  may 
have  subarchitectures,  an  architect  should  carefully  estab¬ 
lish  the  layers  of  variation  points  that  are  introduced 
within  the  product  line  architecture — large  and  highly 
variable  hierarchies  of  elements  may  be  established. 

5.3  Selector 

Once  a  number  of  variation  points  have  been  intro¬ 
duced  in  a  product  line  architecture,  it  becomes  necessary 
to  be  able  to  resolve  those  variation  points  in  order  to 
select  one  or  more  product  architectures  out  of  the  overall 
product  line  architecture.  Selection  by  hand  can  turn  into 


Figure  5.  Selecting  a  Product  Architec¬ 
ture. 

an  arduous  task  given  that  a  product  line  architecture  may 
have  many  variation  points  that  each  may  have  one  or 
more  complex  Boolean  expressions  as  guards.  Therefore, 
Menage  includes  a  Selector  component  to  automate  the 
process. 

Given  a  set  of  desired  properties,  which  are  expressed 
as  typed  name- value  pairs,  and  given  a  starting  point  in 
the  product  line  architecture  (e.g.,  the  “top-level”  compo¬ 
nent  type  from  which  selection  should  begin),  Menage 
iterates  over  the  product  line  architecture  and  attempts  to 
resolve  each  of  the  Boolean  guards  that  it  encounters.  If  it 
can  fully  resolve  a  Boolean  guard  to  true,  the  respective 
element  is  included.  If  it  can  fully  resolve  a  Boolean 
guard  to  false,  the  respective  element  is  removed.  If  a 
Boolean  guard  can  only  be  partially  resolved,  the  element 
is  included  with  the  reduced  Boolean  guard  attached. 
While  a  single  selection  may  only  result  in  a  smaller 
product  line  architecture,  iterative  use  of  the  SELECTOR 
will  eventually  result  in  the  selection  of  a  single  product 
architecture. 

Shown  in  Figure  5,  the  selector  can  operate  in  three 
different  modes.  In  the  first  (“Select”),  it  only  attempts  to 
resolve  variation  points,  but  it  does  not  remove  any  un¬ 


used  types  or  versioned.  In  the  second  (“Prune”),  it  re¬ 
moves  unused  types  and  versions  from  a  product  line 
architecture  to  clean  up  the  specification.  In  the  third  (“Se- 
lect+Prune”),  it  combines  the  two  in  one  step  to  mini¬ 
mize  manual  involvement.  Depending  on  their  purpose, 
an  architect  would  choose  a  preferred  mode  of  operation. 

6.  Evaluation 

To  evaluate  Menage,  we  used  it  to  create  and  evolve  an 
example  product  line  architecture.  Often,  actual  product 
line  architectures  are  considered  important  organizational 
assets  that  cannot  be  shared.  Based  on  limited  informa¬ 
tion  available  on  an  existing  product  line  architecture  for 
consumer  electronics  [31],  we  attempted  to  create  a  repre¬ 
sentative  but  hypothetical  example  of  a  software  product 
line  architecture  for  a  highly  customizable  entertainment 
system.  The  result  of  our  efforts  is  shown  in  Figure  6. 
The  product  line  architecture  consists  of  25  component 
types,  3  connector  types,  and  3  interface  types,  all  avail¬ 
able  in  a  number  of  different  versions.  The  top  level  ele¬ 
ment,  the  EntertainmentSystem,  is  hierarchically  con¬ 
structed  out  of  many  other  components,  some  of  which 
exhibit  further  subarchitectures  (as  indicated  by  the  small 
triangles  in  the  lower  left  comer).  Numerous  variation 
points  exist  in  the  product  line  architecture,  guarded  by  a 
number  of  different  Boolean  guards. 

Our  evaluation  focused  on  how  well  Menage  achieves 
the  four  objectives  listed  in  Section  4.  We  first  examined 
whether  we  were  able  to  create  a  product  line  architecture 
much  like  one  creates  an  architecture  in  an  environment 
such  as  ArchStudio  [20]  or  AcmeS tudio  [14].  For  simple 
architectures,  Menage  operates  exactly  like  those  envi¬ 
ronments.  Only  when  an  architect  must  capture  evolution 
or  specify  a  variation  point,  Menage  incurs  overhead  for 
the  architect.  Overhead  in  general  is  limited  to  a  few  ac¬ 
tions,  except  in  the  case  of  check  out:  an  architect  cur¬ 
rently  must  manually  check  out,  one  by  one,  all  the  ele¬ 
ments  they  intend  to  modify.  This  clearly  is  cumbersome, 
and  will  be  addressed  in  an  upcoming  version  of  Menage 
(see  also  below). 

The  second  objective  states  that  variation  points 
should  be  explicit  within  a  product  line  architecture,  yet 
seamlessly  integrated  in  the  design  process.  Based  on 
creating  the  EntertainmentSystem  product  line  archi¬ 
tecture,  we  believe  we  have  succeeded  in  achieving  this 
goal:  optional,  variant,  and  optional  variant  elements  are 
clearly  identified  in  a  product  line  architecture,  yet  easily 
incorporated  in  much  the  same  way  regular  components 
and  connectors  are  specified. 


Figure  6.  Menage  Applied  to  the  Entertainment  System 

Examole. 


The  third  objective  pertains  to  managing  evolution:  it 
should  be  governed  by  an  explicit  change  management 
process.  Menage  provides  such  a  process  with  its  check 
out  and  check  in  mechanism.  Use  of  these  two  simple 
operations  creates  a  historical  archive  of  all  previous  ver¬ 
sions  of  all  architectural  elements,  regardless  of  whether 
the  element  is  a  simple  interface  type  or  the  complete 
product  line  architecture. 

The  last  objective  is  that  Menage  should  automate  as 
much  of  its  support  as  possible.  Our  experience  in  model¬ 
ing  the  example  product  line  architecture  shows  that  we 
have  achieved  that.  The  selector  component  is  perhaps  the 
chief  example:  based  on  simple  input  from  an  architect,  it 
automatically  selects  the  desired  subset  of  product  archi¬ 
tectures.  As  mentioned  above,  the  check  out  operation  is 
an  exception:  to  reduce  the  manual  effort  of  checking  out 
each  and  every  element  to  be  modified,  we  will  develop  a 
version  of  Menage  that  automatically  and  saliently  checks 
out  an  element  when  an  architect  starts  changing  it.  This 
should  alleviate  much  of  the  burden  imposed  by  the  cur¬ 
rent  change  process. 

7.  Related  Work 

The  work  presented  in  this  paper  draws  from  a  number 
of  research  areas.  Within  the  domain  of  software  architec¬ 
ture,  perhaps  the  two  most  closely  related  technologies  are 
Koala  and  Acme.  Koala  [31,32]  is  an  architecture  descrip¬ 
tion  language  specifically  designed  for  modeling  product 
line  architectures  and,  as  such,  shares  many  of  its  features 
with  Menage.  Compared  to  Menage,  however,  Koala  does 
not  include  a  versioning  mechanism  to  capture  the  evolu¬ 
tion  of  a  product  line  architecture.  Instead,  Koala  relies  on 


an  external  configuration  management  system  to  version 
its  architectural  descriptions.  While  certainly  a  viable  al¬ 
ternative,  this  strategy  prevents  the  incorporation  of  mul¬ 
tiple  versions  of  a  single  component  in  a  single  product 
architecture.  An  additional  drawback  of  Koala  is  that  its 
variability  is  largely  code-based  and  resolved  at  compile¬ 
time  of  a  particular  product;  our  Selector  component  pro¬ 
vides  this  capability  at  the  level  of  product  line  architec¬ 
tures. 

Acme  [14],  as  supported  by  the  AcmeS tudio  environ¬ 
ment,  is  based  on  a  rather  different  mechanism  to  capture 
product  line  architectures.  Instead  of  providing  specific 
language  features,  Acme’s  architecture  description  lan¬ 
guage  is  based  on  the  use  of  constraints  to  model  all  sorts 
of  concepts,  including  styles,  component  and  connector 
types,  and  product  lines.  While  this  provides  the  advan¬ 
tage  of  an  architect  having  to  know  only  a  few  language 
constructs,  it  has  the  distinct  disadvantage  that  it  becomes 
difficult  to  conceptually  separate  logically  different  parts 
of  an  actual  product  line  architecture  specification.  Espe¬ 
cially  when  the  system  to  be  modeled  is  large,  this  rap¬ 
idly  becomes  a  serious  problem. 

UML  [26]  is  a  powerful  modeling  language  that  some¬ 
times  is  proposed  as  a  vehicle  for  modeling  software  ar¬ 
chitectures.  Unfortunately,  support  for  versioning  indi¬ 
vidual  UML  elements  (or  even  whole  UML  diagrams)  and 
for  expressing  variant  elements  are  still  in  their  infancy. 
These  limitations  often  result  in  clumsy  endeavors  relying 
on  external  tools.  Perhaps  even  more  problematic  is  that 
UML  is  a  less  than  optimal  solution  for  modeling  soft¬ 
ware  architectures  (and  thus  product  line  architectures).  Its 
features,  even  when  extended  specifically  for  modeling 


software  architectures,  have  been  demonstrated  to  prevent 
the  accurate  modeling  of  some  architectural  concepts  [25]. 

Feature-oriented  domain  analysis  (FODA)  is  an  area  of 
research  that  has  produced  models  that  are  very  similar  to 
product  line  architectures  [16].  Instead  of  representing 
architectural  elements,  however,  FODA  models  represent 
features  that  may  or  may  not  be  present  in  a  software  sys¬ 
tem.  Not  surprisingly,  FODA  models  include  support  for 
the  various  types  of  variation  points.  FODA,  however, 
still  seems  to  be  in  the  phase  of  finding  proper  languages 
to  represent  features  and  the  authors  are  not  aware  of  any 
extensive  support  environment  for  specifying  particular 
FODA  models,  nor  are  they  aware  of  any  FODA-based 
approaches  that  account  for  the  presence  of  multiple  ver¬ 
sions — a  key  feature  underlying  Menage. 

Finally,  our  work  is  related  to  many  contributions  in 
the  field  of  configuration  management  [8].  In  particular, 
configuration  management  system  models  such  as  Adele 
[13]  and  Proteus  PCL  [29]  provide  similar  mechanisms 
for  modeling  variation  points  within  software  configura¬ 
tions.  While  borrowing  concepts  from  these  system  mod¬ 
els,  our  approach  is  oriented  at  product  line  architectures 
and,  as  such,  is  rooted  in  architectural  concepts  that  are 
not  addressed  by  the  field  of  configuration  management. 

8.  Conclusions 

This  paper  has  presented  Menage,  an  environment  for 
managing  the  evolution  of  product  line  architectures.  Me¬ 
nage  is  unique  in  being  a  graphical  environment  that  pro¬ 
vides  an  architect  with  the  ability  to  specify  and  evolve  a 
product  line  architecture  as  new  product  architectures  are 
added,  existing  product  architectures  are  modified,  and 
obsolete  product  architectures  are  removed.  Key  to  the 
functionality  of  Menage  is  its  tight  integration  of  architec¬ 
tural  design  functionality  (to  manage  the  structure  of  a 
product  line  architecture)  with  configuration  management 
functionality  (to  specify  variation  points  and  manage  the 
evolution  of  a  product  line  architecture). 

We  have  already  embarked  on  three  research  directions 
in  efforts  to  further  enhance  the  functionality  of  Menage. 
First,  we  are  examining  the  role  that  architectural  differ¬ 
encing  and  merging  may  play  in  propagating  changes 
from  one  product  architecture  to  another.  Currently,  an 
architect  has  to  manually  restructure  a  product  line  archi¬ 
tecture  to  do  so,  but  we  intend  to  adapt  our  existing  archi¬ 
tectural  differencing  and  merging  algorithms  (which  only 
operate  on  single  architectures  [30])  to  be  able  to  operate 
on  product  line  architectures. 

Our  second  research  effort  aims  to  support  an  architect 
in  understanding  the  structure  of  a  product  line  architec¬ 
ture.  After  many  changes,  the  overall  structure  generally 
has  disintegrated  and  the  “clean”  design  picture  that  once 
existed  has  deteriorated.  Using  metrics  to  calculate  the 
utilization  of  the  functionalities  provided  by  components 
in  a  product  line  architecture  [12],  we  intend  to  provide  an 
architect  with  graphical  visualizations  that  highlight  po¬ 
tential  structural  problems  in  the  product  line  architecture. 


Typically,  these  problems  indicate  a  need  for  refactoring 
of  elements,  for  instance  splitting  a  particular  variant  in  a 
“smaller”  variant  and  an  optional  element  containing  the 
rest  of  the  functionality. 

Finally,  we  observe  that  a  realization  of  the  full  power 
of  product  line  engineering  requires  a  careful  mapping 
from  the  product  line  architecture  to  actual  source  code 
(components).  Maintaining  such  a  mapping  is  a  difficult 
endeavor  due  to  architectural  erosion.  We  intend  to  de¬ 
velop  a  product  line  architecture-aware  configuration  man¬ 
agement  system  to  aid  in  maintaining  such  a  mapping. 

Availability 

Menage  can  be  downloaded  from  http://www.isr.uci.- 
edu/proj  ects/menage/. 
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